Communication systems and methods

ABSTRACT

Example communication systems and methods are described. In one implementation, a method receives a message from a message server. The method identifies an activity contained in the received message. The received message is modified to indicate, to a user of a client device, an option to create a reminder associated with the activity contained in the received message. The modified message is then communicated to the client device.

RELATED APPLICATION

The present application is a Continuation of co-pending U.S. patentapplication Ser. No. 13/708,055, entitled “Communication Systems andMethods”, filed on Dec. 7, 2012, having Attorney Docket No. 3080.036US1,the disclosure of which is incorporated by reference herein in itsentirety.

TECHNICAL FIELD

The present disclosure relates to communication systems and methods thatprovide supplemental information associated with communicated data.

BACKGROUND

Computing systems are capable of communicating various types of messagesand information to other devices and systems. In some situations, anidentity of a user or system that initiated a particular message isassociated with the message. The identity of the user who initiated theparticular message is useful to the recipient of the message indetermining whether to read the message and in understanding the contextof the message. For example, a user may handle a message received from apotential customer differently than a message received from a potentialvendor. As users receive an increasing number of messages, efficienthandling of these messages may become difficult.

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation inthe figures of the accompanying drawings.

FIG. 1 is a block diagram of an environment within which an exampleembodiment may be deployed.

FIG. 2 is a block diagram of a proxy server, in accordance with someembodiments of the present invention.

FIG. 3 is a block diagram of a supplemental information server, inaccordance with some embodiments of the present invention.

FIG. 4 is a block diagram of a client device, in accordance with someembodiments of the present invention.

FIGS. 5A and 5B illustrate a flow diagram of a method, in accordancewith an embodiment, of handling inbound messages.

FIG. 6 is a flow diagram of a method, in accordance with an embodiment,of handling outbound messages.

FIGS. 7A and 7B illustrate a flow diagram of a method, in accordancewith an embodiment, of transcoding messages.

FIG. 8 depicts, in accordance with an embodiment, a diagram illustratinga sequence and timing of events as they may occur in an IMAP proxyconfiguration.

FIGS. 9-12 depict, in accordance with example embodiments, portions ofuser interfaces displaying various messages and supplementalinformation.

FIG. 13 is a flow diagram of a method, in accordance with an embodiment,of sharing links contained in a message.

FIGS. 14-16 depict, in accordance with example embodiments, portions ofuser interfaces displaying the sharing of links in a message with otherusers.

FIG. 17 is a flow diagram of a method, in accordance with an embodiment,of generating a reminder associated with information contained in one ormore messages.

FIG. 18 depicts, in accordance with example embodiments, a portion of auser interface displaying an option to set a reminder associated withinformation contained in a message.

FIG. 19 is a block diagram of a machine in the example form of acomputer system within which a set of instructions, for causing themachine to perform any one or more of the methodologies discussedherein, may be executed.

DETAILED DESCRIPTION

Example systems and methods of communicating messages are described. Inthe following description, for purposes of explanation, numerousspecific details are set forth in order to provide a thoroughunderstanding of example embodiments. It will be evident, however, toone skilled in the art that the present invention may be practicedwithout these specific details.

The systems and methods described herein modify communication channelswith additional contextual information. The communication channelsinclude, for example, email communications, text message communications,social networking communications, newsgroup communications, web forumcommunications, instant messaging communications, and the like. Theadditional contextual information includes, for example, informationassociated with a sender of a message (such as name, photo, employer,job title, and hobbies), common friends of a recipient and the sender ofthe message, information associated with another recipient of themessage, a map displaying a geographic location identified in themessage, address book information associated with a phone number in themessage, address book information associated with an email address inthe message, and the like.

In some embodiments, the described systems and methods allow users tosee a communication history with other users to refresh their memoryregarding previous topics discussed and past actions performed. Whenreceiving a message from an unknown sender, the described systems andmethods may display a job title, employer, interests, and otherbackground information associated with the sender. This additionalinformation allows the recipient to better understand the messagecontent and respond appropriately to the message. Additionally,providing a photo of a user assists others in identifying the user at ameeting or other event. When attempting to develop a relationship withanother person, a user can gain insight about the other person based on,for example, social media postings and other online communications. Thisinsight may identify topics of mutual interest that provide a startingpoint for a conversation. Additionally, the described systems andmethods allow users to share links and other information with varioususers through, for example, a social network. Users can also make socialnetwork connections with senders or recipients of messages, and performother activities. Further, the described systems and methods allow usersto create a list of links and other information contained in variousmessages that the user wants to review at a later time.

The systems and methods described herein allow users to continue usingtheir existing communication tools while modifying the functionality ofthose communication tools. In particular implementations, the additionalfunctionality is provided through a proxy server associated with thecommunication of messages. The proxy server supports a variety ofcommunication tools and various additional functions associated withthose communication tools. The described systems and methods allow usersto continue using their existing communication tools without changing toa different tool. Additionally, the additional features are available tousers of communication tools that do not directly support third-partyextensions.

FIG. 1 is a block diagram of an environment 100 within which an exampleembodiment may be deployed. A client device 102 communicates with aproxy server 104 and a message server 106. The client device 102 may beany type of device capable of communicating with other servers andsystems, such as a cellular phone, a smart phone, a desktop computer, alaptop computer, a tablet computer, a portable entertainment device, aset top box, a game console, and the like. In some embodiments, theclient device 102 includes a software application that facilitates thecommunication of messages to and from other systems and devices. Theclient device 102 communicates with the proxy server 104 and the messageserver 106 through one or more data communication networks, such as alocal area network (LAN), wide area network (WAN), and the Internet.Although one client device 102 is shown in FIG. 1, a typical environment100 may include any number of client devices 102 coupled to any numberof proxy servers 104 and any number of message servers 106.

The message server 106 receives inbound messages and sends outboundmessages to various other systems. In particular embodiments discussedherein, the message server 106 communicates email messages. However,alternate embodiments of the message server 106 may communicate any typeof message or other information. In some embodiments, the message server106 includes multiple servers coupled to a load balancer, whichdistributes message-related tasks to the multiple servers.

The proxy server 104 receives inbound messages from the message server106 and communicates outbound messages to the message server 106 forprocessing. From a user's perspective, the proxy server 104 providesservices that are similar to, and compatible with, the message server106. A user who wishes to enhance their communications can change theconfiguration of the client device 102 to access the proxy server 104instead of the message server 106. The proxy server 104 communicateswith a supplemental information server 108 and one or more data sources118, which provide, for example, additional information related to amessage, a message sender, a message recipient or a message's content.The proxy server 104 receives message requests, message content, usercredentials, and other information from the client device 102 andcommunicates an appropriate outbound message request to the messageserver 106. Additionally, the proxy server 104 receives inbound messagesfrom the message server 106 and enhances the received inbound messageswith supplemental information.

As discussed herein, the proxy server 104 accepts connection requestsfrom client device 102 and, in turn, the proxy server 104 connects tothe message server 106 as though it were a client. In this example, themessage server 106 may be referred to as an “upstream server” (i.e., theserver that contains the actual message store). In this situation, theproxy server 104 appears as a client to the message server 106. Datasent from the client device 102 to the proxy server 104 is forwarded tothe message server 106, and data sent from the message server 106 to theproxy server 104 is forwarded to the client device 102. As discussedherein, data may be processed, stored, analyzed, and modified as itpasses through the proxy server 104.

In some embodiments, after the client device 102 has authenticateditself, the proxy server 104 can associate the data with otherinformation associated with the same user. This allows the proxy server104 to customize any modifications of the data to the particular userwhose data is being processed. Additionally, the client device 102 canbe configured to report information about itself (e.g., hardware devicetype, software version, and screen size) to the proxy server 104. Theproxy server 104 can then customize any modifications to the data basedon the characteristics and capabilities of the client device 102. Forexample, the proxy server 104 can add minimal data when the clientdevice 102 is a mobile device with a small screen, add more data whenthe client device 102 is a tablet computer, and add the most data whenthe client device 102 is a laptop or desktop computer. The same user canuse the same proxy server 104 with the same credentials on differentclient devices 102 and have a different experience on each client device102, customized to the client device's capabilities and usage.

In particular embodiments, the proxy server 104 communicates emailmessages. However, alternate embodiments of the proxy server 104 maycommunicate any type of message or other information. In someembodiments, the proxy server 104 includes multiple servers coupled to aload balancer, which distributes message-related tasks to the multipleservers. Additional details regarding the operation of the proxy server104 are discussed herein.

The supplemental information server 108 receives information from anynumber of sources, such as a database 110, a first social networkingservice 112, a second social networking service 114, and a socialprofile service 116. The social networking services 112 and 114 includeany type of social network or other social community in which usersshare information about themselves, comments, preferences, hobbies,photos, videos, and other information. The social profile service 116allows users to store or share user profile information, such as name,contact information, career, hobbies, activities, events, and the like.

FIG. 2 is a block diagram of proxy server 104, in accordance with someembodiments of the present invention. The proxy server 104 acceptsinbound connections from client devices in a supported protocol, such asIMAP (Internet Message Access Protocol). For each inbound connection,the proxy server 104 uses a client component 206 to establish aconnection to the appropriate upstream server (an instance of themessage server 106). Requests and data from the client device areforwarded to the upstream server. Similarly, requests and data from theupstream server are forwarded to the client device. Special handlingprocedures are inserted for commands that handle credentials, and forprotocol data that contains messages. Messages are passed through apipeline in which they are parsed, analyzed, manipulated, and re-encodedbefore they are forwarded to the other system. The analysis andmanipulation of messages may make use of one or more supplementalinformation services.

In the example of FIG. 2, an incoming connection from a client device102 is handled by a protocol server 202. On receiving authenticationcredentials from the client device 102, the protocol server 202 providesclient credentials to a credentials processing module 204, which maystore various information in a credentials store 224 or retrieve variousinformation from the credentials store 224. The credentials processingmodule 204 communicates upstream credentials to a protocol client 206,which connects to a message server 106. General requests and generalresponses are communicated between the protocol server 202 and theprotocol client 206. Outbound messages are communicated from theprotocol server 202 to a message parser 208, which parses each of theoutbound messages. A message manipulator 210 manipulates outboundmessages and a message encoder 212 re-encodes outbound messages in astandard message format. The message encoder 212 communicates theencoded outbound message to the protocol client 206.

Inbound messages are communicated from the protocol client 206 to amessage parser 220, a message manipulator 216, and a message encoder214. The message encoder 214 communicates the encoded inbound message tothe protocol server 202. A device friendly formatting module 218interacts with the message manipulator 216 to properly format inboundmessages for the device that will be receiving and displaying theinbound message. The message parser 220 and the device friendlyformatting module 218 also communicate with a supplemental informationservice 222, which provides various supplemental information that may beadded to particular inbound messages. In some embodiments, the messageparser 220 provides constituent data (e.g., any type of informationassociated with a sender of the inbound message) to the supplementalinformation service 222, which uses the constituent data to identifyappropriate supplemental information. The constituent data includes, forexample, an identity of a sender of the message, an identity of at leastone other recipient of the message, a geographic location or postaladdress, a phone number, an email address, an activity request, a URL(uniform resource locator), a name of a person, a name of a company, alanguage of the message, a unique message identifier, an indicator ofimportance or urgency or an indicator of an unwanted message.

FIG. 3 is a block diagram of the supplemental information server 108, inaccordance with some embodiments of the present invention. In variousembodiments, the supplemental information server 108 implements computerprograms, logic, applications, methods, processes, or software formanaging supplemental information as described herein. The supplementalinformation server 108 includes a communication module 302, a socialnetwork management module 304, a user profile management module 306, adatabase management module 308, and a supplemental data sourcemanagement module 310, coupled to one another via a data communicationbus 312. The communication module 302 allows the supplementalinformation server 108 to communicate with other components and systems(e.g., the proxy server 104, the data source 118, the social profileservice 116, the social networking services 112 and 114, and the like).

The social network management module 304 manages various interactionwith, for example, the social networking services 112 and 114, such asthe retrieval of data from the social networking services 112 and 114 aswell as the storage of data to the social networking services 112 and114. The user profile management module 306 manages interaction with,for example, the social profile service 116, such as the retrieval ofdata from and the storage of data to the social profile service 116. Thedatabase management module 308 manages various data storage functionsassociated with one or more data storage devices, such as the database110. The supplemental data source management module 310 managesinteraction with, for example, the data source 118 and other sources ofsupplemental information. In some embodiments, the supplemental datasource management module 310 retrieves data from the data source 118 foruse by the supplemental information server 108. The data communicationbus 312 allows the various systems and components of the supplementalinformation server 108 to communicate with one another.

FIG. 4 is a block diagram of the client device 102, in accordance withsome embodiments of the present invention. In various embodiments, theclient device 102 implements computer programs, logic, applications,methods, processes, or software to perform various functions, asdescribed herein. The client device 102 includes a communication module402, a messaging application 404, and a user interface generator 406,coupled to one another via a data communication bus 408. Thecommunication module 402 allows the client device 102 to communicatewith other components and systems (e.g., the proxy server 104, themessage server 106, and the like).

The messaging application 404 supports various message-relatedfunctions, such as the generation of messages, the display of messages,the sending of messages, and the receipt of messages. The user interfacegenerator 406 creates data to present various user interfaces to a userof the client device 102, such as message display interfaces, userprofile interfaces, message sharing interfaces, and the like. The datacommunication bus 408 allows the various systems and components of theclient device 102 to communicate with one another.

FIGS. 5A and 5B illustrate a flow diagram of a method 500, in accordancewith an embodiment, of handling inbound messages. Initially, a user of aclient device activates a messaging application on the client device at502. A messaging application includes any application that is capable ofreceiving, creating, editing or otherwise handling any type of message.The message may be of any format and contain any type of data. Examplemessages include an email message, a social media message, a newsgroupmessage, a calendar synchronization message, a voicemail message, a textmessage, an address book entry, an audio message, and a video message.

In some embodiments, the client device communicates a user ID, apassword, a client device type, and a message server ID to a proxyserver at 504. For example, the user ID and other informationcommunicated to the proxy server is associated with a messaging account(e.g., an email account) of the user. The proxy server communicates theuser ID and password to a message server associated with the user'smessaging account at 506. The message server is identified, for example,based on the message server ID communicated to the proxy server from theclient device.

In some embodiments, the proxy server requests a listing of availablemessages associated with the user's messaging account from the messageserver at 508. In other embodiments, the proxy server may request aparticular message (e.g., a specific message identified by the user ofthe client device) from the message server. The proxy server receivesthe requested listing of available messages at 510 and communicates thelisting to the client device for presentation to the user at 512. Theclient device requests (in response to user input) a message from theproxy server by specifying a message identifier at 514 associated with adesired message. The proxy server requests the selected message from themessage server by specifying the message identifier at 516.

The proxy server receives the requested message from the message serverat 518. The proxy server then identifies supplemental informationassociated with a sender of the requested message at 520. Thesupplemental information includes, for example:

-   -   information associated with a sender of the message,    -   information associated with another recipient of the message,    -   a map displaying a geographic location identified in the        message,    -   information related to an email address, phone number, URL, name        or other identifier contained in the message, where that        information is obtained from an address book, a customer        relationship management (CRM) system, a vendor relationship        management (VRM) system, an applicant tracking system (ATS), an        order fulfillment system, a customer support system, an        enterprise resource planning (ERP) system, a note-taking system,        a task management system or any other privately or publicly        accessible database,    -   an option to add an activity request to a reminder list        associated with the user of the client device,    -   an option to share a URL contained in the message on at least        one social network,    -   an option to translate the message into another language,    -   common connections (e.g., friends or social connections) of the        user of the client device and the sender of the message,    -   an indicator of an importance or urgency of the message,    -   a time zone of a geographic location identified in the message,    -   a time zone of a geographic location associated with the sender        of the message,    -   a history of previous communications with the sender of the        message using the same communication medium, and    -   a history of previous communications with the sender of the        message using another communication medium.

Based on the known client device type, the proxy server adjusts the sizeand format of the supplemental information based on the client devicetype at 522. For example, the proxy server may make adjustments based ona display size of the client device, computing resources of the clientdevice, a storage capacity of the client device, display resolutionssupported by the client device, and the like. These adjustments may makeuse of a database of devices which stores, for example, the displayresolution and software capabilities for a known set of device models.Additionally, the proxy server may adjust a font size, font type, fontcolor or other formatting characteristics of the message and/or thesupplemental information. The proxy server then modifies the requestedmessage to include the supplemental information associated with thesender at 524. After modifying the requested message, the proxy servercommunicates the modified message to the client device at 526. Theclient device presents the modified message to the user of the clientdevice at 528.

The example of FIGS. 5A and 5B identifies supplemental information basedon the sender of the requested message. In alternate embodiments, thesupplemental information can be identified based on any type of datacontained in or associated with the requested message. For example, thesupplemental information can be associated with an identity of at leastone other recipient of the message, a geographic location or postaladdress of the sender of the message, a phone number associated with thesender of the message, an email address associated with the sender ofthe message, an activity request associated with the message, a URL(uniform resource locator) contained in the message, a languageassociated with the message, an indicator associated with the importanceor urgency of the message, and an indicator identifying the message asan unwanted message. On other embodiments, the supplemental informationis identified based on any two or more of the above-identified dataexamples.

FIG. 6 is a flow diagram of a method 600, in accordance with anembodiment, of handling outbound messages. Initially, a user of a clientdevice generates a message at 602, for example by replying to anexisting message, by forwarding an existing message, or by starting anew conversation thread. The client device communicates the message to aproxy server at 604. The proxy server receives the message at 606. Ifthe message was generated by reply or forwarding of an existing message,and that existing message was previously modified by a proxy server 104to contain supplemental information, then the client device 102 mayembed that supplemental information in the outbound message, for examplein the form of a quotation. At 608, the proxy server may search themessage for any such existing supplemental information, and remove,replace or rewrite it as appropriate. The proxy server may also identifysupplemental information associated with the sender or at least one ofthe intended recipients of the message at 610. As discussed above withrespect to FIGS. 5A and 5B, alternate embodiments may identifysupplemental information associated with any type of data contained in(or associated with) the message. The method 600 continues as the proxyserver modifies the message to include the supplemental information at612. The proxy server then communicates the modified message to amessage server for distribution to the intended recipient at 614. Asdiscussed herein, the supplemental information may include any type ofinformation, such as the examples provided herein with respect to FIGS.5A and 5B.

The proxy server 104 discussed herein may include multiple differenttypes of servers, such as an IMAP (Internet Message Access Protocol)proxy server, an Exchange ActiveSync proxy server, and an SMTP (SimpleMail Transfer Protocol) proxy server. In some embodiments, a singleproxy server handles both inbound messages and outbound messages. Inother embodiments, inbound messages are handled by one proxy server andoutbound messages are handled by a different proxy server, such as anIMAP proxy server for inbound messages and an SMTP proxy server foroutbound messages. The following discussion provides example embodimentsof various types of proxy servers.

IMAP Proxy Server

To the client device 102, the proxy server 104 presents itself as astandards-compliant IMAP server. To upstream servers (e.g., the messageserver 106), the proxy server 104 presents itself as astandards-compliant IMAP client. In some embodiments, the proxy server104 supports authentication with username and password as theauthentication mechanism. The proxy server 104 does not need to maintainits own user database, since it can delegate authentication to themessage server 106. If a client issues a CAPABILITY command before theproxy server 104 is connected to the message server 106, the proxyserver 104 will report its own capabilities.

Since different users may use different message servers 106 with thesame proxy server 104, the name or address of the message server 106 isencoded in the credentials sent by the client device 102. This techniqueis also used to encode properties of the client device 102. For example,if the client device 102 is an Apple iPad® tablet running iOS version5.1, and the client wants to access user “martin@rapportive.com” on themessage server “imap.gmail.com”, then the client device 102 couldcombine all of this information into the IMAP LOGIN username, such as“d=ipad:v=5.1:s=imap.gmail.com:u=martin@rapportive.com”. The proxyserver 104 parses that username string, and uses “martin@rapportive.com”as the username when connecting to the message server “imap.gmail.com”.Alternatively, an opaque unique identifier can be used as username, ifthe proxy server 104 maintains a mapping from those identifiers to themessage server 106 account details. Other fields may be added to theusername string. If any of the fields are not to be modified by users, aHMAC (hash-based message authentication code) or other authenticationcode may be used to prevent users from tampering with the usernamestring.

In some embodiments, it is advisable to include information about theconnection and the message server 106 into the username string, andleave the password string unchanged. In some situations, users oftenchange their password, but very rarely change their username. In thesesituations, if the message server 106 rejects the login, the proxyserver 104 can forward the rejection to the client device 102, and theclient device 102 can prompt the user for their new password withoutchanging the username. When the client device 102 retries with the sameusername and the new password, the proxy server 104 can forward the newpassword to the message server 106 without requiring any specialhandling.

FIG. 8 depicts, in accordance with an embodiment, a diagram 800illustrating a sequence and timing of events as they may occur in anIMAP proxy configuration. After establishing a connection to the IMAPproxy server, the client device typically performs a TLS (TransportLayer Security) handshake to establish a secure channel beforeattempting login. When the IMAP proxy server receives the credentials,it extracts the upstream server hostname from the username field,connects to the upstream server, establishes a secure channel using TLS,and attempts login using the upstream username and password. The successor failure of the upstream login attempt can then be passed on to theclient device.

Once the client device 102 is authenticated, the proxy server 104 cansafely pass through most commands received from the client device 102,and corresponding responses from the message server 106, withoutmodification. In FIG. 8 this is illustrated with the “Select Inbox”command. Further processing is performed for FETCH, UID FETCH or APPEND(and possibly other) commands received from the client device 102, andthe corresponding responses from the message server 106, described asfollows.

FETCH commands are used by the client device 102 for various purposes,such as downloading a summary of all messages in a mailbox, downloadingthe full text of a selected message or downloading message attachments.FIG. 8 illustrates two uses of FETCH, whereby the client first downloadsheaders of all messages in the inbox, and then downloads the full bodyof selected messages. In some embodiments, information contained in themessage headers may be used to “prime” or “pre-warm” a cache ofsupplemental information, so that a subsequent FETCH request for thefull body may be processed faster. For example, if the sender's emailaddress is being used to search for supplemental information, the emailaddresses can be extracted from the message headers. This primingoperation may occur asynchronously: at the same time as the messageheaders are returned to the client device, the supplemental informationservice may begin to process the email addresses.

When a FETCH command for a message body (or part of a message body) issent by the client device, as illustrated by “Fetch Message” in FIG. 8,the proxy server first fetches that message or message part from theupstream server. It then passes the message to a transcoding process,which may call upon a supplemental information service, which may inturn make use of any number of social profile services. Requests tothose social profile services may be made synchronously duringtranscoding, or may be made on an independent schedule and cached. Thetranscoded message is then returned to the client.

The FETCH command allows clients to request specific parts (“dataitems”) of a message, such as one particular MIME part, without anyheaders. The data items requested by a particular FETCH command from theclient device 102 may not contain all of the information required by theproxy server 104 to perform the required message rewriting function. Forexample, if the sender email address is required, the proxy server 104requires the BODY[HEADER.FIELDS (FROM)] data item, and in order tocorrectly transform MIME structures, it requires the BODYSTRUCTURE dataitem if the other data items in the request are for specific MIME partsrather than the entire body. If the FETCH request is for an attachment,and the application does not call for rewriting of attachments, then noadditional data items may be required.

The data items not requested by the client device 102 for a particularmessage, but required by the proxy server 104 for correct rewriting, maybe obtained in various ways. One option is for the proxy server 104 tomaintain its own persistent store for this message metadata by sequencenumber or UID by appropriately keeping track of changes in sequencenumbering and UIDVALIDITY. If a persistent store is not desired, theproxy server 104 may insert additional requested data items into FETCHrequests received from the client device 102 as they are forwarded tothe message server 106, so that the corresponding response from themessage server 106 contains all of the data items required for correctrewriting of the messages. Any data items added to a FETCH request areremoved from the corresponding response by the proxy server 104 beforeit is forwarded to the client device 102, to maintain protocolcorrectness.

Certain existing implementations of the message server 106 may havebugs, with the effect that even if a client requests an additionalheader field, such as the BODY[HEADER.FIELDS (FROM)] data item, it isnot returned by the message server 106. The IMAP proxy server 104 maywork around such bugs by performing an additional FETCH request to themessage server 106, using the same sequence set, requesting only suchheader fields. In these embodiments of the proxy server 104 that issueadditional commands, a lock is taken to prevent the client device 102from concurrently issuing commands that alter the overall state of theIMAP connection, such as SELECT, until the additional command andresponse cycle have completed.

The message server 106's response to a FETCH request is processed by theproxy server 104 as follows. Any BODY[ ] data item in the response isprocessed as described in the section on message rewriting below. AnyBODYSTRUCTURE data item in the response is modified in a manner that isconsistent with the message rewriting rules, in particular, any changeof character encoding or content type of any MIME part (such as thereplacement of a text/plain part by a text/html part) is also reflectedhere. Any BODY[HEADER] data item in the response, containing aContent-Type header, is similarly modified in a manner that isconsistent with the message rewriting rules. Any RFC822.SIZE data itemin the response may be updated to reflect the size of the message afterrewriting has occurred. Other data items that were originally requestedby the client device 102 may be passed through without modification.

If an application needs a strict one-to-one correspondence between theset of messages reported by the message server 106 and the set ofmessages reported by the proxy server 104 to the client device 102, thenany message sequence numbers and UIDs may be passed between the messageserver 106 and the client device 102 without modification. However, ifan application requires that the set of messages seen by the clientdevice 102 be modified (for example, that messages of low importanceshould be hidden when reading the contents of a particular mailbox, orfor introducing virtual mailboxes as described below), then the proxyserver 104 maintains a mapping between the client device 102 and themessage server 106's respective views of sequence numbers and UIDs.Additionally, the proxy server 104 translates them in both directions inall commands and responses. Sequence numbers obey IMAP's contract of notexhibiting gaps in the sequence, but since the mapping is local to asession, it does not require persistent storage. With UIDs, gaps areallowed. Thus, as long as messages are hidden and not added by the proxyserver 104, the proxy server 104 can use the same UID values forcommunicating with the client device 102 as it uses for communicatingwith the message server 106. If the application needs the client device102 to be presented with messages that do not exist on the messageserver 106 (such as system notifications that apply to this particularclient device 102), then, to comply with IMAP protocol requirements, theproxy server 104 persistently stores, for each message, the UIDpresented by the message server 106 and the UID presented to the clientdevice 102 (which may be different, and either UID may be absent if themessage was inserted or hidden by the proxy server 104).

If an application wishes to introduce virtual mailboxes (i.e., mailboxesthat are visible to the client device 102 but do not exist on themessage server 106, and whose contents are determined by the results ofa search query or some other processing), or to rename mailboxes (e.g.,to ensure that sent messages are placed in the designated sent itemsfolder on the message server 106), then the proxy server 104 alsointercepts the LIST, SELECT, EXAMINE, STATUS, CREATE, DELETE, RENAME,SUBSCRIBE, UNSUBSCRIBE, and LSUB commands and their associatedresponses. The virtual or renamed mailbox name is inserted intoresponses containing lists of mailbox names, and requests including avirtual mailbox name are not forwarded to the message server 106, orrenamed in reverse before forwarding to the message server 106. In avirtual mailbox scenario, the application will need to determineappropriate semantics for the COPY command and propagation of messageflags (e.g., \Seen and \Deleted).

APPEND commands most commonly appear in conjunction with sending amessage via SMTP, which occurs on a separate connection. The IMAP APPENDcommand is used to save a message to the user's “sent mail” folder.Users expect the messages in their “sent mail” folder to be theidentical to the messages received by their respective recipients(modulo headers added in MTA (Message Transfer Agent) transit), so themessage that appears with APPEND is modified by the IMAP proxy server inthe same way as the same message is modified by the SMTP proxy,discussed below.

Exchange ActiveSync Proxy Server

In Exchange ActiveSync, the user is authenticated with a username and apassword, encoded using the HTTP Basic authentication scheme. TheAuthorization header is typically included on all POST requests made bythe client, and the Exchange ActiveSync proxy server can simply passthis header through to the message server 106. Exchange ActiveSync alsouses HTTP OPTIONS requests, which typically do not include anAuthorization header. However, OPTIONS requests are still forwarded bythe Exchange ActiveSync proxy server to the message server 106, in orderto detect the Exchange server version and other information. It istherefore not sufficient to encode the message server 106 name in theusername, like described in the case of the IMAP proxy server, becausethe Exchange ActiveSync proxy server would not know which message server106 to use for an OPTIONS request. Instead, the described systems andmethods use the fact that HTTP includes the full hostname in a Hostheader. Combined with a wildcard DNS record, it is possible to encodearbitrary information in a subdomain name. For example, if the messageserver 106 is “exchange01.upstream.com”, first, to escape the periods,replace “.” by “0-” and “0” by “00”. If the DNS for“*.activesync.example.com” resolves to the IP address of the ExchangeActiveSync proxy, the client device 102 can now be configured to connectto “exchange0010-upstream-0com.activesync.example.com”. The escaping ofperiods is necessary because although the DNS wildcard covers multiplelevels of subdomains, wildcard SSL certificates cover a single level ofsubdomain. By encoding the full upstream server name in just one levelof subdomain, a wildcard SSL certificate for “*.activesync.example.com”is accepted as valid by clients.

When the client device 102 makes a request to the Exchange ActiveSyncserver, the request cannot be blindly forward it to the message server106 because each request includes a “DeviceId” parameter, and themessage server 106 maintains synchronization state information for eachcombination of username and DeviceId. Unfortunately, it is possible fora user to have two email accounts for the same user configured on thesame client device 102, one using the proxy server and one connectingdirectly to the message server 106. If this happens, the client device102 considers the two connections to the two servers (i.e., the ExchangeActiveSync proxy server and the message server 106) to have differentsynchronization states from each other, but the message server 106 seesidentical DeviceIds and therefore applies the same synchronization stateto both connections. This leads to undefined results. To solve thisproblem, the Exchange ActiveSync proxy server modifies the DeviceId onclient device 102 requests to be some other string, not equal to anyother client device 102 used by the same user. Typically, appending anarbitrary suffix to the DeviceId is sufficient.

Thus, on each request sent from the client device 102 to the ExchangeActiveSync proxy server, the DeviceId parameter is replaced, and theHost header is replaced to refer to the message server's hostname. Ifthe response from the message server 106 contains any Set-Cookie headersthat include the message server's hostname, the Exchange ActiveSyncproxy server rewrites them to use the Exchange ActiveSync proxy server'sencoded subdomain in the cookie's domain field. The HTTP request andresponse bodies can safely be passed by the Exchange ActiveSync proxyserver, except on the Sync, SendMail, SmartForward, and SmartReplycommands, as described below.

Sync commands from the client device 102 are not modified by theExchange ActiveSync proxy server, but the client's WBXML (Wirelessapplication protocol Binary XML) request body is parsed to determine thetype of sync. For example, AirSync:GetChanges with a value of 0 may beused by the client device 102 to indicate the download of a particularmessage, rather than a sync of folder contents, and theAirSyncBase:BodyPreference element may be sent by client devices toindicate the requested message format (plain text, HTML, RTF or MIME)and truncation of message contents. This information is used in messagetranscoding, to ensure the message is given to the client device 102 inthe format expected by the client device 102.

The WBXML in the Sync command response from the message server 106 needsto be decoded and searched for any AirSync:Fetch elements that arechildren of an AirSync:Responses element, and any AirSync:Add orAirSync:Change elements that are children of a AirSync:Commands element.Such elements may contain an email message or another type of message(e.g., a meeting invitation). Email messages can be detected byexamining whether the AirSync:ApplicationData/Email:MessageClass valueis “IPM.Note”. An application that wishes to only process email messagescan pass through messages with other MessageClass values withoutmodification, but other applications may want to also enhance calendarentries and other types of messages.

For email messages that are to be parsed and modified, the content type(AirSyncBase:Type) is inspected, which may be plain text, HTML, RTF orMIME. In the case of plain text or HTML, the code page value in theEmail:InternetCPID element is used to determine the message's characterencoding, and if character encoding normalization is applied, thiselement is updated with the code page ID of the normalized encoding.Together with this content type information, the message data(AirSyncBase:Data element) can be passed to the message transcoding andenhancement layers, discussed below. The content type of the messagecannot safely be modified as the returned message format needs to matchthe format request by the client device 102, but the message data can bereplaced with the enhanced version before reassembling the WBXMLresponse and sending it to the client device 102.

When sending a message, the client device 102 uses the SendMail,SmartReply or SmartForward command. Typically, the outbound message iscontained in the client device's request body in a ComposeMail:MIMEelement. This message is used both for transmission to the message'srecipients and for saving to the user's “sent mail” folder. The ExchangeActiveSync proxy server modifies this message in the same way as theSMTP proxy server, discussed herein, and the modified SendMail,SmartReply or SmartForward request is sent to the message server 106.

SMTP Proxy Server

SMTP is intended to allow intermediary servers in the transmission ofmessages, and the use of SMTP intermediary or SMTP proxy servers (e.g.,for archival purposes) is common. The approach described herein differsfrom common SMTP intermediaries in that the SMTP proxy server acts as aMail Submission Agent for the client device 102, and typically usesanother Mail Submission Agent as the message server 106. In thisconfiguration, the recipients' Mail Transfer Agents see messages ascoming from the user's normal message server 106, which reduces the riskthat they will be marked as spam.

Mail Submission Agents like the message server 106 typically require theuser to authenticate with username and password before allowing messagesto be submitted. This means that when configuring the client device 102to connect to the SMTP proxy server, the message server's hostname canbe encoded in the username, in the same manner as described for the IMAPproxy server above. When connecting to the message server 106, the SMTPproxy server extracts the original username from the composite string ofupstream hostname and original username supplied by the client device102.

After the client device 102 has connected, but before it hasauthenticated, the SMTP proxy server responds to commands based on itsown capabilities, independently of any message server 106. After aclient device 102 has provided credentials, and the message server 106has successfully authenticated the user, the SMTP proxy server forwardsthe client device's commands to the message server 106, and forwards themessage server's responses to the client device 102.

Following a DATA command from the client device 102, the SMTP proxyserver accepts the subsequent message in Internet Message Format, andpasses it to the message transcoding layer, discussed herein, indicatingthat it is dealing with an outbound message sent by the user (ratherthan an inbound message received by the user). The resulting modifiedmessage is sent to the message server 106 with the forwarded DATAcommand.

Message Transcoding

FIGS. 7A and 7B illustrate a flow diagram of a method 700, in accordancewith an embodiment, of transcoding messages. In some embodiments, atleast a portion of the method 700 is performed by the proxy server 104,discussed herein. Initially, an email message is received at 702. Themethod 700 determines whether the message is in Internet message formatat 704. If the message is in Internet message format, the message's MIMEstructure is parsed at 706. The method 700 also normalizes the encodingof the message body at 708 and parses the metadata from the MIME headersand/or the message body at 710. If the message is determined not to bein Internet message format at 704, the method 700 normalizes thecharacter encoding of the message body at 712 and parses the metadatafrom the protocol context and/or the message body at 714.

The method 700 continues by using the parsed metadata to identifysupplemental information associated with the message at 716. This mayinvolve communicating with any number of supplemental informationservers 108 or data sources 118. The method 700 then determines whetherthe message is in HTML format at 718. If the message is not in HTMLformat, the method 700 converts the message to HTML format if a changeof content type is permitted by the message's protocol at 720. Themethod 700 enhances the message by inserting supplemental informationinto the message at 722.

The message determines, at 724, whether the message is in Internetmessage format. If the message is in Internet message format, the method700 updates the MIME container with the enhanced message body at 726. Ifthe message is not in Internet message format, the method 700 updatesthe protocol container with the enhanced message body at 728. The method700 continues by serializing the message into a format that isappropriate based on the context of the enhancement in the messageprotocol at 730. Finally, the message is communicated to an appropriatesystem or client device at 732.

The following example presents a specific embodiment of a messagetranscoding procedure. A message transcoding and enhancement layeraccepts as input an email message, extracted from one of the emailprotocol proxy servers 104 described herein. As a minimum, the proxyserver 104 supports Internet Message Format, plain text, and HTML asinput and output formats. In the case of plain text and HTML input, theproxy server 104 allows the character encoding and related header fields(such as the sender and recipient email addresses of the message) to bespecified. In the case of Internet Message Format, that information iscontained within the header fields of the message. The proxy server 104supports two distinct modes of operation: inbound (a message received bythe user) and outbound (a message sent by the user). In the case ofinbound messages, details of the authenticated user account, the clientdevice type, and the client software version are also specified.

If the message to be transcoded is in Internet Message Format, its MIMEstructure is parsed, as described in RFCs 2045, 2046, 2047 and 2049. Inthe case of multipart messages, the body parts that are displayed byclients are identified (i.e., parts that are not attachments, or lesspreferable multipart/alternative versions, etc.). These visible bodyparts are typically either in plain text or in HTML format, and they maybe processed in the same way as messages that were provided to thetranscoding layer as plain text or HTML, as described below.

Once the message body is in plain text or HTML, its character encodingis normalized, in order to facilitate the modification of the messagewith data from other sources. In some embodiments, UTF-8 (UCSTransformation Format-8 bit) is used for character encoding, as manycharacter encodings can be converted into UTF-8 losslessly, and it issupported by a variety of client devices. The message body, and themetadata obtained from message headers or the email protocol (such asthe email addresses of the sender and the recipients), are parsed andused to query any number of databases or services to find informationthat may be used to enhance the message. Such queries may consider dataspecific to the authenticated user.

Next, the message body is analyzed for any existing enhancements, orfragments of enhancements, contained within the message (for example, ascontained in a quoted reply in the case of an outbound message). Suchenhancement may be recognized by certain element IDs or class names usedin the HTML source, or by certain invisible unicode character sequencesin the text, or any other distinctive feature appropriate to theapplication. Such existing enhancements may be deleted from the message,or replaced with alternative representations, as appropriate.

Next, if the message is in plain text and if the transcoding isperformed in a context that allows use of HTML instead of plain text,then the plain text message is converted to equivalent HTML. Since linebreaks are ignored in HTML, line breaks in the plain text message areconverted into explicit line break or paragraph elements in the HTMLconversion. To allow reflow of the message text on screens of differentsizes, the conversion may insert explicit line breaks for those newlines that were explicitly entered by the user, and not for line breaksthat were introduced by the sender's client by wrapping a long paragraphinto multiple lines.

Next, using the results of the database and service queries describedabove, the message is enhanced. This is done by inserting content intothe message at any number of points. If the message is in plain text andcannot be converted into HTML, these modifications are made in plaintext, and may be differentiated from the rest of the message usingpunctuation or other symbols. Otherwise, the modifications are made byadding HTML elements, which may be styled, for example, using CSS(cascading style sheets), and may include images, links, and any othercontent appropriate to the application. Any actions that the user maytake can be represented as links to websites, other applications orother kinds of external references.

The same enhancement information may be expressed and represented indifferent forms, structures or styles. When modifying the message, theenhancement process may take into account the context when choosingwhich expression of the information to insert into the message. Inparticular embodiments, on inbound messages, the knowledge of the clientdevice type and client software version may be used to render arepresentation tailored to the screen size, visual style, hardware andsoftware capabilities, and other characteristics of that client device(for example, CSS animations may be employed if they are supported bythe client device). On outbound messages, the representation ofinformation inserted into the message can be optimized for compatibilitywith a wide range of different email clients, since it is not known onwhich client device or client software the message will be read.

Interactive user interfaces may be created within the modified messageby taking advantage of certain device capabilities. For example, partsof the user interface may be made visible at the user's request by usingCSS :hover, :active and :focus pseudo-classes, even in environmentswhere execution of JavaScript is not permitted. Animated graphicsformats and other techniques may also be used. Since these capabilitiesare typically present on some models of client device 102, they willtypically be generated on inbound messages where the client device typeand software version is known to the message transcoding process.

For messages in Internet Message Format, in addition to insertingcontent into the HTML body part, it may be appropriate to add furtherMIME parts to the message, such as using the multipart/related containertype. This can be used to include images in the message such that theycan be referenced in the HTML part, and displayed by clients withoutneeding to download any external resources. For multipart/relatedcontainers that cannot be nested, any existing container should bereused if it exists. If it does not exist, a multipart/related containercan be inserted at the position of the HTML body part in the MIME tree,and the HTML body part is made a child of that container.

After these enhancements have taken place, the message is serializedinto a format most suitable to the context of the enhancement in theemail protocol, which may be plain text, HTML or Internet MessageFormat. In this re-serialization, information present in the originalmessage is kept intact as much as possible. For example, attachments arepreserved and not modified. Also, certain clients may include HTMLstructures or character encodings that are not standards-compliant. Tominimize unintended side-effects of the proxy server on the user's emailexperience, such structures are preserved as far as possible. If anyunrecoverable error occurs during the enhancement process, someembodiments revert to using the unenhanced message. The serializedenhanced message is returned to the email protocol proxy server fromwhich it came, and embedded into the communication stream.

In some embodiments, the message transcoding and enhancement processreplaces one message with a completely different message. For example,this may be appropriate for messages sent by the operator of the proxyserver itself. When viewed on an email account that is not using theproxy server, such a message could include instructions on how to set upthe proxy server configuration. However, when downloaded by a clientthat is already configured to use the proxy server, it could notify theuser of a successful configuration.

FIGS. 9-12 depict, in accordance with example embodiments, portions ofuser interfaces displaying various messages and supplementalinformation. FIG. 9 illustrates an example email message received from asender “John Smith.” In addition to the email message 902, the originalmessage has been modified to include supplemental information 904associated with John Smith. In this example, the supplementalinformation 904 includes a picture of John Smith, employment informationassociated with John Smith, as well as his educational experience. Thesupplemental information 904 also provides links to connect with JohnSmith on various social networks.

In some embodiments, the user may activate a button in order to expandthe supplemental information displayed in the message. FIG. 10illustrates the email message of FIG. 9 after the supplementalinformation has been expanded. In the example of FIG. 10, additionalsupplemental information associated with John Smith is shown, includingvarious networks used by John Smith. The recipient of the email messagecan activate any of the network names or icons to initiate a networkconnection with John Smith or to learn more about his activity on eachnetwork. Further, the email message shown in FIG. 10 identifies severalusers connected with both the email recipient and John Smith. Thesecommon connections may provide credibility and/or context regarding theemail content to the email recipient.

FIG. 11 illustrates an example email message being prepared by JohnSmith and sent to Mark Jackson, the email recipient. In this example,supplemental information associated with Mark Jackson is automaticallyinserted into the email message as it is created by John Smith.Displaying this supplemental information to the user creating themessage provides confirmation that the correct email recipient has beenselected.

FIG. 12 illustrates an example portion of a user interface that displaysan invitation to join another user's network. In some embodiments, anemail recipient will see supplemental information inserted into thereceived email message. The email recipient can activate one of thelinks or icons included in the email message to invoke an invitationdialog, such as the example in FIG. 12. The email recipient mayoptionally write a message to the other user, and can then choose toinvite the other user to join their network.

FIG. 13 is a flow diagram of a method 1300, in accordance with anembodiment, of sharing links contained in a message, such as an emailmessage. Initially, the method 1300 identifies a received message at1302 and identifies one or more links in the received message at 1304.The method 1300 selects links in the received message that containshareable content at 1306. Example shareable content includes contentthat is publicly accessible and/or would be relevant to another user. Aspecific example of a shareable link is a link to an online article thatis publicly accessible to other users. The links that contain shareablecontent are displayed to a user at 1308. The user may choose to activateone or more of the selected links at 1310. If the user activates atleast one of the selected links, the method 1300 displays an option toshare the activated link with other users at 1312. If the user activatesthe option to share the activated link at 1314, the method 1300 displaysa dialog box that allows the user to define how to share the link withother users at 1316. For example, the user may share the link via email,a social network connection, and the like. After displaying the dialogbox, the method 1300 awaits further user instructions at 1318.

FIGS. 14-16 depict, in accordance with example embodiments, portions ofuser interfaces displaying the sharing of links in a message with otherusers. FIG. 14 illustrates an example email message that includes a linkto an article 1402. When the recipient of the email message hovers overthe link 1402 (or otherwise identifies the link 1402), the userinterface displays one or more options as shown by way of example inFIG. 15. In the example of FIG. 15, the user interface displays a dialogbox 1502 that identifies other users (e.g., network connections) whohave shared the same link 1402 with others. Additionally, the dialog box1502 identifies options to share the link 1402 via a social network orother connection mechanism, mark the link 1402 for visiting/reading at afuture time, comment on the link 1402, and like the content of the link1402. In alternate embodiments, any number of different options may bepresented to a user for sharing, saving or otherwise managing the link1402.

FIG. 16 illustrates an example email message including a dialog box 1602that allows a user to post comments to a social network, a group or toone or more individuals. The comments may be related to the emailmessage content, a link in the email message, an email attachment, atopic mentioned in the email message content, and the like.

FIG. 17 is a flow diagram of a method 1700, in accordance with anembodiment, of generating a reminder associated with informationcontained in one or more messages. Initially, the method 1700 identifiesa received message at 1702 and analyzes the content of the receivedmessage to identify potential activities, events or other itemscontained in the received message at 1704. The potential activities,events or other items include meetings, conferences, phone calls,personal activities, project deadlines, tasks, and the like. The method1700 displays the received message to a user at 1706. Additionally, themethod 1700 displays the potential activities, events or other items tothe user as well as a link to create a reminder for the potentialactivities, events or other items at 1708. If the user chooses whetherto activate the reminder link at 1710, the potential activities, eventsor other items are added to a calendar, task list, or othersystem/application at 1712. For example, if the potential activity is ameeting, the method 1700 may automatically add the meeting to the user'scalendar program in response to the user activation of the reminderlink. Finally, the method 1700 awaits further user instructions at 1714.

FIG. 18 depicts, in accordance with example embodiments, a portion of auser interface displaying an option to set a reminder associated withinformation contained in a message. The example email message contentshown in FIG. 18 includes “Could you please get the figures to me bynoon tomorrow so that I can include them in the slide deck?” Based onthis email message content, an application or system determines that theemail recipient may want to set a reminder for the next day at noon.Accordingly, the application or system displays a “remind me” button orlink 1802 that allows the email recipient to set a reminder to providethe requested information by noon the next day. If the email recipientactivates the button or link 1802, the reminder is automatically enteredin the email recipient's calendar, task list or other task managementapplication.

FIG. 19 is a block diagram of a machine in the example form of acomputer system 1900 within which instructions, for causing the machineto perform any one or more of the methodologies discussed herein, may beexecuted. In alternative embodiments, the machine operates as astandalone device or may be connected (e.g., networked) to othermachines. In a networked deployment, the machine may operate in thecapacity of a server or a client machine in server-client networkenvironment, or as a peer machine in a peer-to-peer (or distributed)network environment. The machine may be a personal computer (PC), atablet PC, a set-top box (STB), a Personal Digital Assistant (PDA), acellular telephone, a web appliance, a network router, switch or bridge,or any machine capable of executing instructions (sequential orotherwise) that specify actions to be taken by that machine. Further,while a single machine is illustrated, the term “machine” shall also betaken to include any collection of machines that individually or jointlyexecute a set (or multiple sets) of instructions to perform any one ormore of the methodologies discussed herein.

Example computer system 1900 includes a processor 1902 (e.g., a centralprocessing unit (CPU), a graphics processing unit (GPU) or both), a mainmemory 1904, and a static memory 1906, which communicate with each othervia a bus 1908. Computer system 1900 may further include a video displaydevice 1910 (e.g., a liquid crystal display (LCD) or a cathode ray tube(CRT)). Computer system 1900 also includes an alphanumeric input device1912 (e.g., a keyboard), a user interface (UI) navigation device 1914(e.g., a mouse), a disk drive unit 1916, a signal generation device 1918(e.g., a speaker) and a network interface device 1920.

Disk drive unit 1916 includes a machine-readable medium 1922 on which isstored one or more sets of instructions and data structures (e.g.,software) 1924 embodying or utilized by any one or more of themethodologies or functions described herein. Instructions 1924 may alsoreside, completely or at least partially, within main memory 1904,within static memory 1906, and/or within processor 1902 during executionthereof by computer system 1900, main memory 1904 and processor 1902also constituting machine-readable media.

While machine-readable medium 1922 is shown in an example embodiment tobe a single medium, the term “machine-readable medium” may include asingle medium or multiple media (e.g., a centralized or distributeddatabase, and/or associated caches and servers) that store the one ormore instructions or data structures. The term “machine-readable medium”shall also be taken to include any tangible medium that is capable ofstoring, encoding or carrying instructions for execution by the machineand that cause the machine to perform any one or more of themethodologies of the present invention, or that is capable of storing,encoding or carrying data structures utilized by or associated with suchinstructions. The term “machine-readable medium” shall accordingly betaken to include, but not be limited to, solid-state memories, andoptical and magnetic media. Specific examples of machine-readable mediainclude non-volatile memory, including by way of example semiconductormemory devices, e.g., Erasable Programmable Read-Only Memory (EPROM),Electrically Erasable Programmable Read-Only Memory (EEPROM), and flashmemory devices; magnetic disks such as internal hard disks and removabledisks; magneto-optical disks; and CD-ROM and DVD-ROM disks.

Instructions 1924 may further be transmitted or received over acommunications network 1926 using a transmission medium. Instructions1924 may be transmitted using network interface device 1920 and any oneof a number of well-known transfer protocols (e.g., HTTP). Examples ofcommunication networks include a local area network (“LAN”), a wide areanetwork (“WAN”), the Internet, mobile telephone networks, Plain OldTelephone (POTS) networks, and wireless data networks (e.g., WiFi andWiMAX networks). The term “transmission medium” shall be taken toinclude any intangible medium that is capable of storing, encoding orcarrying instructions for execution by the machine, and includes digitalor analog communications signals or other intangible media to facilitatecommunication of such software.

Although an embodiment has been described with reference to specificexample embodiments, it will be evident that various modifications andchanges may be made to these embodiments without departing from thebroader scope of the invention. For example, the described systems andmethods may provide an educational benefit in other disciplines that byproviding incentives for users to access the systems and methods.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense. The accompanying drawingsthat form a part hereof, show by way of illustration, and not oflimitation, specific embodiments in which the subject matter may bepracticed. The embodiments illustrated are described in sufficientdetail to enable those skilled in the art to practice the teachingsdisclosed herein. Other embodiments may be utilized and derivedtherefrom, such that structural and logical substitutions and changesmay be made without departing from the scope of this disclosure. ThisDetailed Description, therefore, is not to be taken in a limiting sense,and the scope of various embodiments is defined only by the appendedclaims, along with the full range of equivalents to which such claimsare entitled.

Such embodiments of the inventive subject matter may be referred toherein, individually and/or collectively, by the term “invention” merelyfor convenience and without intending to voluntarily limit the scope ofthis application to any single invention or inventive concept if morethan one is in fact disclosed. Thus, although specific embodiments havebeen illustrated and described herein, it should be appreciated that anyarrangement calculated to achieve the same purpose may be substitutedfor the specific embodiments shown. This disclosure is intended to coverany and all adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, will be apparent to those of skill in theart upon reviewing the above description.

What is claimed is:
 1. A computer-implemented method comprising:receiving a message from a message server; identifying an activitycontained in the received message; modifying, using one or moreprocessors, the received message to indicate, to a user of a clientdevice, an option to create a reminder associated with the activitycontained in the received message; and communicating the modifiedmessage to the client device.
 2. The method of claim 1, furthercomprising receiving an indication from the client device that the userof the client device selected the option to create a reminder associatedwith the activity contained in the received message.
 3. The method ofclaim 2, further comprising associating a task management systemassociated with the user.
 4. The method of claim 3, further comprisingcreating the reminder associated with the activity in the taskmanagement system.
 5. The method of claim 1, the option to create thereminder associated with the activity including date informationassociated with the activity.
 6. The method of claim 1, the option tocreate the reminder associated with the activity including timeinformation associated with the activity.
 7. The method of claim 1, theoption to create the reminder associated with the activity includinglocation information associated with the activity.
 8. The method ofclaim 1, the received message including at least one of an emailmessage, a social media message, a newsgroup message, a calendarsynchronization message, a voicemail message, a text message, an addressbook entry, an audio message, and a video message.
 9. The method ofclaim 1, further comprising: determining a device type associated withthe client device; and adjusting a display size of the modified messagebased on the device type.
 10. The method of claim 1, further comprising:determining a device type associated with the client device; andadjusting a formatting of the modified message based on the device type.11. A computer-implemented method comprising: establishing a connectionto a proxy server, the proxy server configured to receive messages froma message server; receiving a message from the proxy server; identifyingan indication of an option to create a reminder associated with anactivity contained in the received message; causing display of theoption to create a reminder to a user; determining, using one or moreprocessors, whether the user selected the option to create a reminder;and responsive to determining that the user selected the option tocreate a reminder, communicating the determination to the proxy server.12. The method of claim 11, further comprising receiving anidentification from the user of a task management system to receive thereminder.
 13. The method of claim 12, further comprising communicatingidentification of the task management system to the proxy server. 14.The method of claim 12, further comprising creating a reminder in thetask management system.
 15. The method of claim 11, the option to createa reminder including at least one of a date associated with theactivity, a time associated with the activity, and a location associatedwith the activity.
 16. An apparatus comprising: a memory to store dataassociated with messages received from a message server; and one or moreprocessors coupled to the memory, the one or more processors configuredto: receive a message from a message server; identify an activitycontained in the received message; modify the received message toindicate, to a user of a client device, an option to create a reminderassociated with the activity contained in the received message; andcommunicate the modified message to the client device.
 17. The apparatusof claim 16, the one or more processors further configured to receive anindication from the client device that the user of the client deviceselected the option to create a reminder associated with the activitycontained in the received message.
 18. The apparatus of claim 16, theone or more processors further configured to associate a task managementsystem with the user.
 19. The apparatus of claim 18, the one or moreprocessors further configured to create the reminder associated with theactivity in the task management system.
 20. The apparatus of claim 16,the option to create a reminder including at least one of a dateassociated with the activity, a time associated with the activity, and alocation associated with the activity.